Hi @ALIIQBAL786 ,

Thanks for creating the Backlog issue and the API proposal PR, and for sharing the supporting material. It’s good to see a potential new API that could be incorporated into the CAMARA API family. I’ll include the proposal in next week’s Backlog agenda.

Before the session, a few quick points that came up while reading the proposal (we can cover everything live in the Backlog call):

• CAMARA capability vs MEC wrapper: today it can read as “a CAMARA façade over ETSI MEC 030 via a Transformation Function”. It would help to explicitly define the northbound service semantics (key entities/resources and portability expectations) and keep the TF/MEC mapping as implementation guidance.

• Service API vs Operate/Platform boundary: terms like “provisioning” (especially anything that sounds like radio/network provisioning) may trigger out-of-scope concerns. Please make clear this is developer-facing service exposure (service-level configuration/info needed by apps/vehicles), not network management.

• Overlap positioning: since you reference QoS/QoD and other CAMARA APIs, please clearly state what is in-scope for V2X Exposure and what is out-of-scope (covered by existing CAMARA APIs). Otherwise the discussion risks getting stuck on “this API does too much”.

• Subscriptions alignment: if you propose a unified subscription entry point for multiple event types, make sure it follows CAMARA/Commonalities subscription patterns. Even before YAML, a short description of subscription semantics (filters/geo scoping, event types, error model) in the PR will make the review much more concrete.

Hi @ALIIQBAL786,

Thanks all for the offline exchanges so far. We received a message from Gianmarco at nextgcloud, and we've been discussing the API proposal internally.

To keep the evaluation transparent and aligned with the normal CAMARA backlog process, I think the discussion should continue here in the backlog thread rather than through additional 1:1 discussions.

After reviewing the current material and the feedback shared so far, we do not think the proposal is yet sufficiently framed as a concrete CAMARA API demand.

At the moment, the slides read more like a connected ambulance / V2X solution architecture than a clearly isolated CAMARA northbound API capability. The material combines a vertical use case, ETSI MEC V2X Information Service, a Transformation Function, QoD/QoS composition, and potentially additional APIs. In that form, it is still unclear what the single concrete CAMARA capability is that should be proposed here.

From a CAMARA perspective, it would be important to reformulate the proposal in a more focused and use case-neutral way. In particular, please update the backlog material to clarify:

1. One concrete candidate capability only: Please avoid describing a broad “V2X API” or the overall connected ambulance solution. Instead, isolate one specific candidate capability that CAMARA should define.

2. CAMARA northbound semantics independently of MEC: Please define the canonical entities/resources, expected behavior, portability expectations across operators, and what is left to implementation. MEC mapping / TF logic can be useful as implementation guidance, but should not be the core definition of the CAMARA API.

3. Clear scope boundary: Please explain what is in scope for the proposed API and what is explicitly out of scope, especially versus existing CAMARA APIs and versus Operate/platform concerns.

4. Explicit overlap / gap analysis: Since the slides already reference QoD/QoS and other CAMARA capabilities, please explain what is already covered by the current CAMARA portfolio, what could be composed from existing APIs, and what concrete gap remains.

5. Subscription model, if applicable: If eventing/subscriptions are part of the proposal, please describe the event types, filters (including geo scoping if relevant), lifecycle, and error model in a way aligned with CAMARA/Commonalities patterns.

6. Operator support / implementation realism: Please indicate which operator(s) realistically see this as a candidate CAMARA API to implement and maintain, and whether the proposal depends on enablers/platform functions that cannot be assumed to exist broadly across operators.

If useful, you may add one high-level diagram only insofar as it helps explain that single candidate capability. I would avoid expanding the full PoC solution architecture further unless it directly helps clarify the API proposal itself.

Once the proposal is updated in that form, it will be easier for the backlog group to assess whether:

• there is a real need for a new CAMARA API,
• the topic should instead be addressed by composition of existing CAMARA APIs, or
• the topic is outside CAMARA scope.

CC: @tanjadegroot, @hdamker, @MarkusKuemmerle